NoSQL DB Hardening Checklist

Following are the best practices:

  1. Enable Access Control and Enforce Authentication

    Enable access control and specify the authentication mechanism. You can use MongoDB's SCRAM or x.509 authentication mechanism or integrate with your existing Kerberos/LDAP infrastructure. All clients and servers provide valid credentials before they can connect to the system.

  2. Configure Role-Based Access Control

    • Create a user administrator, then create additional users. Create a unique MongoDB user for each person/application that accesses the system.

    • Follow the principle of least privilege. Create roles that define the exact access rights required by a set of users. Then create users and assign them only the roles they need to perform their operations. A user can be a person or a client application.

  3. Encrypt Communication (TLS/SSL)

    Configure MongoDB to use TLS/SSL for all incoming and outgoing connections. Use TLS/SSL to encrypt communication between MongoD and MongoS components of a MongoDB deployment as well as between all applications and MongoDB.

    Starting in version 4.0, MongoDB uses the native TLS/SSL OS libraries.

  4. Disable HTTP Status Interface

    MongoDB, by default, provides an http interface running on port 28017 which provides the home status page. This interface is not recommended for production use and is best disabled. Use the “nohttpinterface” configuration setting to disable the http interface:

    nohttpinterface = true

  5. Encrypt and Protect Data

    1. Encrypting data at rest. Encrypt the data where it is stored. At rest encryption is not available for MongoDB Community Edition; it requires MongoDB Enterprise or MongoDB Atlas.

      • Starting with MongoDB Enterprise 3.2, you can encrypt data in the storage layer with the WiredTiger storage engine's native Encryption at Rest.

      • If you are not using WiredTiger's encryption at rest, MongoDB data should be encrypted on each host using file system, device, or physical encryption (e.g. dm-crypt). Protect MongoDB data using file-system permissions. MongoDB data includes data files, configuration files, auditing logs, and key files.

      • Collect logs to a central log store. These logs contain DB authentication attempts including source IP address.

    2. Encrypting data in transit. By default, with MongoDB, all data is encrypted in transit using TLS. Even if all the connections are behind firewalls and there’s no external exposure, those internal connections still need to use TLS to reduce the risk that a breach of an environment will lead to additional database breaches.

  6. Limit Network Exposure

    • Ensure that MongoDB runs in a trusted network environment and configure firewall or security groups to control inbound and outbound traffic for your MongoDB instances.

    • Disable direct SSH root access.

    • Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available.

  7. Audit System Activity

    1. Audit trails should track who made changes to the configuration of the database, what those changes were and when the changes were made. With its audit framework, MongoDB Enterprise offers a full audit trail of administrative actions.

      • The log file is not encrypted as a part of MongoDB's encrypted storage engine. A MongoD running with logging may output potentially sensitive information to log files as a part of normal operations, depending on the configured log verbosity.

      • MongoDB 3.4 Enterprise provides the security.redactClientLogData setting to prevent potentially sensitive information from entering the Mongod process log. redactClientLogData reduces detail in the log and may complicate log diagnostics. See the log redaction manual entry for more information.

    2. MongoDB supports the execution of JavaScript code for certain server-side operations: mapReduce, $where, $accumulator, and $function. If you do not use these operations, disable server-side scripting by using the --no scripting option on the command line.

    3. The auditing facility can write audit events to the console, the syslog, a JSON file, or a BSON file. To enable auditing for MongoDB Enterprise, see Configure Auditing.
      Audit Events and Filter - Once enabled, the auditing system can record the following operations.

      • schema (DDL)

      • replica set and sharded cluster

      • authentication and authorization

      • CRUD operations (requires auditAuthorizationSuccess set to true).

      • For details on audited actions, see Audit Event Actions, Details, and Results.

      For information on the audit log messages, see System Event Audit Messages.

  8. Input Validation

    NoSQL databases are still vulnerable to injection attacks so only pass it to the validated known input. Use of parameterization in your application frameworks and other best practices for passing un-trusted input to a database is required.